前言

前一篇我們講了什麼是微服務、微服務的特性、和單體氏架構不同的地方，從今天開始大概會有3-4篇的文章在講Request Driven，其中包含：

• Request Driven的特性
• 相比單體氏架構，Request Driven的優點
• RESTFul API
• Request Driven所面臨的挑戰

好的～讓我們開始吧！！

Request Driven Architecture

隨著微服務(Microservices)架構的普及，應用端的設計模式不斷在演化和改變，當我們探討微服務架構時常會提到兩種主要的架構，分別是：

• Request Driven Architecture
• Event Driven Architecture

至今為止，Request Driven Architecture依然是大部分的工程師使用的架構之一，原因在於其入門門檻不高，設計理念傾向簡單好懂。

前面說了那麼多，到底什麼是Request Driven呢？

Request Driven是一種Request與Reply的互動模式，在這種架構中，程式的服務之間透過同步Request(請求)-Reply(回應)的方式進行互動，就是我們所說的Synchronous pattern。

說的有點抽象，讓我們簡單舉例：

以電商平台為例：

如果今天有一位顧客打開了電商平台的網站，做了以下幾件事情：

1. 瀏覽商品
2. 點開特定商品
3. 購買商品

乍看之下沒什麼，實際上伺服端做了很多同步的處理：

1. 發送特定商品的詳細資訊請求: 當顧客點選特定商品的圖示，電商平台會向伺服器發送一個請求，期望能得到該商品的詳細資訊，包含價格、顏色、庫存、甚至銷售程度等。
2. 伺服端收到並處理請求：伺服端收到請求後，透過帶來的資訊去資料庫尋找這筆商品的詳細資訊並包裝成回應回給電商平台，平台在傳送到網頁供顧客瀏覽。
3. 發送購買商品的請求: 顧客選完相關條件，像是尺寸、顏色，接著點擊“購買“。這時平台將購買商品的請求發送給伺服端，包含顧客的付款資訊等。
4. 伺服端收到並處理購買請求： 伺服端收到購買的請求後，會先做一系列的驗證，確認無誤之後再將資訊包裝成回應給平台，平台再傳送到網頁告知顧客訂單成功提交。

當顧客從瀏覽到購買商品的過程中，與伺服端的每一次互動都是一次的的同步Request-Reply模式。如果這些互動過程中的每一次都無法即時處理，顧客在等待的過程中，購買慾望可能會下降，甚至就不買了。

Request Driven的特點

• 同步(Synchronous): 每次的服務請求都是同步的，意思是請求端得等伺服端完成才能進行下一步
• 簡單好懂:由於同步的特性，開發人員可以很容易追蹤請求與回應的流向。

總結

Request Driven Architecture是微服務架構的一種常見的設計模式，透過其簡單好懂的特性得到眾多工程師的喜愛。然而，隨著系統的規模擴大，該架構還是有不少的挑戰需要克服，之後的篇章會為大家說明。

好了～～今天就到這邊！！